Migrate to schema and column editor API#12488
Conversation
greg0ire
force-pushed
the
schema-editor
branch
4 times, most recently
from
9ca3ec4 to
53d56ad
Compare
|
@beberlei could you be more specific? This PR represents the changes in the ORM internals, the new DBAL API is for the DBAL consumers (e.g. the ORM) — how does it reflect whether it's hard or not for the ORM users? FWIW, most of the new tests in the DBAL have been written using the new API and I haven't heard any complaints about the API being hard to use. |
greg0ire
force-pushed
the
schema-editor
branch
4 times, most recently
from
5c2c764 to
6eebd12
Compare
|
@beberlei right now, I've focused on fixing the deprecations reported in the test suite, so the code is not fully migrated to the editor APIs. Moreover, I have to keep the code backward compatible with DBAL versions where this API do not exist. I think whether the API is easy to use or not will be easier to judge once the migration is complete, and the BC code is cleaned up (so, on 4.0.x, after a merge up). Granted, the new API is less convenient to use, but it's a tradeoff and the benefits outlined in doctrine/dbal#6660 look IMO worth the change. |
greg0ire
requested review from
GromNaN,
SenseException,
beberlei,
derrabus,
morozov and
stof
3 participants
These are the minimal changes needed to make the build green. My plan is to rebase #12357 on this (and probably retarget to 3.6.x as well, since it is about addressing deprecations, although for some reason there aren't any).